home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Mac100% 1998 November
/
MAC100-1998-11.ISO.7z
/
MAC100-1998-11.ISO
/
オンラインソフト定点観測
/
ユーティリティ
/
Mops 3.2.sea
/
Mops 3.2
/
Mops 3.2 release notes
next >
Wrap
Text File
|
1998-07-04
|
7KB
|
205 lines
================== Mops 3.2 RELEASE NOTES ===================
Here is the usual "release notes" describing the changes from the previous
Mops versions, so that those already using it don't have to wade through all
the documentation (or have to read right through the huge manual!!!).
The date of this release is July 1998. If you've received it more than six
months later, it might be an idea to check the Web site to see if there's a
later version.
First, here are my contact details:
------------------------------------------------------------------------
Mike Hore email: mikeh@zeta.org.au
Mops web page: http://www.netaxs.com/~jayfar/mops.html
snail-mail: _--_|¥
Michael Hore / ¥
54 Frederick St, ¥_.--._*
Sydenham NSW 2044, v
AUSTRALIA.
------------------------------------------------------------------------
Mops 3.2 is basically a consolidation release. It fixes quite a
number of minor bugs, some of which have been around for a while.
It also has a number of improvements under the hood, and the
PowerMops code has been generally cleaned up.
The Glossary (which you get to via Quick Edit) is now completely
revised, and up to date. This has been overdue for a loooong
time!
There are a couple of things that I promised for this release
which still haven't made it, notably the ability to generate
a shared library. Since I'll be away for most of August, it
seemed best to go ahead with this release now, rather than
wait until I get back.
This release only has a few new features which weren't in 3.1 --
basically features of 68k Mops which were still to be implemented
in PowerMops.
The changes weren't sufficient to justify a new manual release,
so the manual is still the 3.1 release version. The extra features
are described below.
BUGS FIXED
==========
1. In 68k Mops, if you did something like this:
variable vb
: crash vb w@x 1000 > if 1 then ;
an illegal instruction would get generated.
2. Also in 68k Mops, if a SysCall word returns a short (a 16-bit
quantity), the sign wasn't always extended, and you could get junk in the high
16 bits. This means that negative Toolbox error codes didn't always get
returned properly. This only happened on some Macs and systems.
3. In PowerMops, on some Macs, there would be a crash while trying to
build the system. An illegal address was actually being dereferenced,
and on most systems this didn't matter.
4. I also ran into a number of code generation bugs in PowerMops which
didn't affect most code, but may have caused strange crashes. These
are all now fixed.
Note that the problem given in the FAQ, for which I promised a fix,
isn't fixed yet. It didn't make it to the top of my "to-do" stack
in time. However, it's more an annoyance than a major bug:
If you highlight multiple lines in the Mops window (or in
QuickEdit) and hit enter, the interpretation doesn't quite follow
the rules for normal multi-line interpretation. This is because
it uses EVALUATE, which doesn't know about multiple lines. There
was an attempt to handle "¥" - type comments, but it wasn't
successful, and the only result was that you couldn't do [CHAR] ¥
and get what you expected.
Anyway I definitely should get this fixed for the next release.
NEW FEATURES IMPLEMENTED
====================
* Local sections for methods are now implemented in PowerMops,
as for 68k Mops.
* Ability to be able to call a shared library in PowerMops.
(See below for details.) Note that we can't generate a
shared library yet -- hopefully this will make it into the
next release.
* Assertions (Also see below.)
* Cache for late-bound calls. This is transparent to users,
but gives a useful speedup to many late-bound calls --
especially in loops, where it counts. If a late-bound call
hits in the cache, the overhead is reduced from around
500 machine instructions to about 200.
CALLING A SHARED LIBRARY (PowerMops only)
=========================================
You do this in a rather similar way to calling the system.
You must first declare your library, like this:
library MySharedLib
(As with SYSCALL, the library name is case sensitive.)
Then before any definition which calls the library, you
must declare your call, using the word EXTERN (rather
like SYSCALL for calling the system). The syntax is:
EXTERN <lib_name> <call_name>
( #result_cells #parm1_cells ... #parmN_cells N -- )
(Again the call name is case sensitive.)
Example:
1 1 1 1 3 extern mySharedLib myCall
¥ 1 result cell, 3 1-cell parameters
We need to specify all this parameter and result information
since Mops doesn't otherwise have it available (unlike system
calls, for which we have the xcalls file).
We specify each parameter separately since we must be able
to indicate which if any are floating point (we'll see
how to do this shortly).
The number of result cells will be either 0 or 1. This is
determined by the C/Pascal convention. We have to observe
this convention for shared libraries, since one of their
important features is that they can be called from any
language.
If any of your parameters or results are floating, you
specify this by passing the constant kFloat in the respective
parameter or result position. So, let's say that the shared
library MathLib was being called this way. We'd declare the
cos function like this:
library MathLib
kFloat kFloat 1 extern MathLib cos
ASSERTIONS
==========
Assertions are provided by a number of programming languages,
and are a very useful way of catching bugs. Assertions
allow you, during development, to ensure that things are the
way they're supposed to be at key places.
Mops assertions must come within definitions. You use
them like this:
ASSERT{ <something that evaluates to a flag> }
If ASSERTIONS? is true, this will give error 216 ("assertion failed")
if the evaluated flag is false. If ASSERTIONS? is false, nothing
will happen - the code between ASSERT{ and } is skipped.
ASSERTIONS? can be defined and redefined however and whenever you
like, as long as it returns a flag. ASSERT{ tests it via EVALUATE,
so the most recently defined definition will be the one that gets
looked at. You can define it at the start of your project, or at
the start of each source file, or more often. It's up to you.
This way you can enable or disable ASSERT{ to suit whatever
you're doing in your project development.
Note also, wherever you have ASSERTIONS? defined as a constant with
value false, no code will even be compiled for the assertion test.
You can use this for code that you know works, so that there's no
performance penalty whatever.
--------------------------------------------------------------------
As always, I hope you enjoy Mops!
ム- Mike Hore mikeh@zeta.org.au